Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-atm-classic-ip-01.txt < prev next >

Wrap

Text File | 1993-07-08 | 26.5 KB | 676 lines

Network Working Group Mark Laubach Request for Comments: DRAFT Hewlett-Packard Laboratories Expires January 5, 1994 July 5, 1993 Classical IP and ARP over ATM Status of this Memo This document is an internet draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the lid-abstracts.txt listing contained in the internet-drafts shadow directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or munnari.oz.au to learn the current status of any Internet Draft. 1. Abstract This memo describes an initial application of classical IP and ARP in an ATM network environment configured as a Logical IP Subnetwork (LIS) as described below and in [1]. This memo does not preclude the subsequent development of ATM technology into areas other than an LIS; specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This document considers only the application of ATM a as a direct replacement for the "wires" and local LAN segments connecting IP end-stations and routers. Issues raised by MAC level bridging are beyond the scope of this paper. 3. Acknowledgment This memo could not have come into being without the critical review from Jim Forster of Cisco Systems, Drew Perkins of FORE Systems, and Bryan Lyles, Steve Deering, and Berry Kercheval of XEROX PARC. The concepts and models presented in [1], written by Dave Piscitello and Laubach [Page 1] DRAFT Classical IP and ARP over ATM July 1993 Joseph Lawrence, laid the structural groundwork for this work. This document could have not been completed without the expertise of the IP over ATM Working Group of the IETF. 4. Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL, or MANDATORY -- the item is an absolute requirement of the specification. o SHOULD or RECOMMEND -- this item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- the item is truly optional and may be followed or ignored according to the needs of the implementor. 5. Introduction The goal of this specification is to allow compatible and interoperable implementations for transmitting IP datagrams and ARP requests and replies over ATM Adaptation Layer 5 (AAL5)[6]. Currently, ATM standards are being defined in the ITU-TSS (formally CCITT), ANSI and the ATM-FORUM. ITU-TSS and ANSI are defining standards for public ATM networks. The ATM-FORUM is not a recognized standards body, however they are addressing the application of ATM in the local environment and there is substantial public involvement. It is the intent of this document to follow ITU-TSS standards except where the ATM-FORUM provides needed functionality. Initial deployment of ATM provides a LAN segment replacement for ethernet networks and as wire-replacement for dedicated public telecommunication lines between IP routers. In the former model, local IP routers with one or more ATM interfaces will connect islands of local ATM networks. ATM-FORUM compliant addressing will be used within these local ATM networks. In the latter model, public ATM networks will be used to connect IP routers, which in turn may or may not connect to local ATM networks. Public networks will use ITU-TSS and ANSI standards for addressing in ATM. ATM-FORUM compliant addressing cannot be guaranteed in public ATM networks. The characteristics and features of ATM networks are different than those found in LAN's: o ATM provides a virtual circuit switched environment. VC setup may be done on either a Permanent Virtual Circuit (PVC) or dynamic Switched Virtual Circuit (SVC) basis. SVC call management Laubach [Page 2] DRAFT Classical IP and ARP over ATM July 1993 signalling is performed via Q.93B implementations [7,9]. o Data to be passed by a VC is segmented into 53 octet quantities called cells (5 octets of ATM header and 48 octets of data). ATM networks provide very low latency switching, high throughput, and the ability to multiplex VC's of differing quality of service. o Each VC carries a type which identifies a specific format for the exchange of protocol data units (PDU's). These formats are called ATM Adaptation Layers (AAL's) and are typed from 1 through 5. AAL5 specifies a packet format with a maximum size of 64K user data octets. Cells for an AAL5 PDU are transmitted first to last, the last cell indicating end of PDU. ATM standards guarantee that on a given VC, cell ordering is preserved end-to-end. o ATM-FORUM signalling defines point-to-point and point-to- multipoint addressing [9]. Multicast service addressing is not yet a conformance requirement of the ATM-FORUM. o ATM-FORUM local LAN addresses are hardware addresses using the same format as NSAP's. This memo describes the initial deployment of ATM within "classical" IP networks as a direct replacement for local area networks (ethernets) and for IP links which interconnect routers, either within or between administrative domains. The "classical" model here refers to the treatment of the ATM host adapter as a networking interface to the IP protocol stack. Characteristics of the classical model are: o One default maximum MTU size for the network interface, consistent with current implementations. o Default LLC/SNAP encapsulation of IP packets, with administrator allowed reconfiguration. o IP destinations map to VC's via ARP and route lookups, consistent with current model. o ARP's stay within the LIS, current ARP architecture stays the same. o One IP subnet used for many hosts/routers. A separate VC is used for each host/router pair, one subnet is used for all these VC's. The "global" ATM model is an evolution of the classical model where the ATM network becomes more fully deployed and globally available. Laubach [Page 3] DRAFT Classical IP and ARP over ATM July 1993 In this model, the traditional protocol stack architecture evolves allowing applications to map directly on VC's (e.g., TCP and UDP ports map directly onto VC's) and ARP mechanisms are no longer bound to LIS boundaries as queries and replies may go global. IP will evolve to take advantage of the network services provided by the global ATM network. Characteristics of the global model are: o MTU size negotiated per VC via ATM signalling, requires MTU size be separated from interface in protocol stack. o Encapsulation negotiated per VC via ATM signalling, requires common signalling to be implemented and globally available. o Any applications map to VC's, requires changes to TCP/UDP/IP to allow ports to map directly on to VC's o ARP's can go global, ARP architecture needs to change to support a robust global client/server model. o Differing quality of service (QOS) guarantees will exist on a per application and per VC basis. The deployment of ATM into the internet community is beginning and will take several years to implement. During this period, we expect deployment to follow traditional IP subnet boundaries for the following reasons: o Administrators and managers of IP subnetworks will tend to initially follow the same models as they currently have deployed. The mindset of the community will change slowly over time as ATM increases its coverage and builds its credibility. o Policy administration practices rely on the security, access, routing, and filtering capability of IP Internet gateways: i.e. firewalls. ATM will not be allowed to "back-door" these mechanisms until ATM provides better management capability than the existing services and practices. This memo details the treatment of the classical model of IP and ARP over ATM. There are those would like to have IP-over-ATM begin by breaking the classical model - this memo represents the view that we must walk before we can run. This memo does not preclude the subsequent evolution of ATM networks as they become more globally deployed and interconnected and the evolution of TCP and IP to take advantage of these changes - these will be the subject of future documents. This memo does not address issues related to transparent Laubach [Page 4] DRAFT Classical IP and ARP over ATM July 1993 data link layer interoperability. 6. IP Subnetwork Configuration This section describes the scenario for an ATM network that is configured with one or more Logical IP Subnetworks (LIS's). The scenario considers only directly connected IP hosts or routers reachable via switched virtual circuits (SVC's). In the LIS scenario, each separate administrative entity configures its hosts and routers within a closed logical IP subnetwork. Each LIS operates and communicates independently of other LIS's over the same ATM network. Hosts connected to ATM communicate directly to other hosts within the same LIS. Communication to hosts outside of the local LIS is provided via an IP router. This router would be a station attached to the ATM network that may have been configured as a member of two or more LIS's. This configuration results in a number of disjoint LIS's operating over the same ATM network. Hosts of differing IP subnets would communicate via an intermediate router even though a direct virtual circuit between the two hosts may be available over the ATM network. The requirements for IP member stations (hosts, routers) operating in an ATM LIS configuration are: o All members have the same IP network/subnet number. o All stations within an LIS are accessed directly over the ATM network. o All stations outside of the LIS are accessed via a router. o All members of an LIS must have a mechanism for resolving IP addresses to ATM addresses via ARP [4] when using SVC's. o All members within a LIS MUST be able to communicate with all other members in the same LIS; i.e., the topology is fully meshed. There should be no administrative restrictions at the ATM level that prevent VC's from operating between all pair of stations. The following list identifies a set of ATM specific parameters that MUST be implemented in each IP station which would connect to the ATM network. The parameter values MUST be user configurable: o ATM Hardware Address (atm$ha). The ATM individual address of the IP station. Each host must be configured to accept datagrams destined for this address Laubach [Page 5] DRAFT Classical IP and ARP over ATM July 1993 o ATM ARP Request Address (atm$arp-req). The ATM hardware address (point-to-point or multicast) to which ARP requests are to be sent for the resolution of target protocol addresses to target hardware addresses for SVC connections. Three cases are available: 1. atm$arp-req is atm$ha, the local machine ATM hardware address. The local host may either consult its ARP translation table directly, or preferably to support ARP queries by loopback internally or externally via the ATM network. In the case of an external loopback, a VC is dedicated specifically for ARP queries and replies. This case is called the "Loopback ARP" model. 2. atm$arp-req is the ATM hardware unicast address of an individual ARP server located within the LIS. That server must have authoritative responsibility for resolving ARP requests all IP stations within the LIS. The VC's connecting IP stations to this ARP server are dedicated specifically for ARP queries and replies. An individual client connects to the ARP server using a point-to-point (unicast) connection. The server, upon receiving connections from new clients, will add the client address to a single point-to-multipoint group. Queries to the server are received on the unicast VC from the client. The server responds on the multipoint VC enabling all clients receive the reply. This case is called the "ARP Server" model. 3. atm$arp-req is an ATM hardware group (multicast) address. If the ATM switching fabric supports ATM hardware multicast, then a well known VC using the ATM group address local to the LIS is dedicated specifically for broadcast ARP queries and replies and IP packets sent to the IP broadcast address. The ARP query/reply service on all IP stations within the LIS MUST be reachable via this address. This case is called the "Multicast ARP" model. It is RECOMMENDED that the ARP Server model be implemented within an LIS. The use of redundant ARP servers however, reachable via a group address, is beyond the scope of this document. The Multicast ARP model is attractive in that it more closely models the well known ethernet service of which the community has many years of experience. There are some technical details that need to be worked out involving the simultaneous transmission of multi-cell AAL5 PDU's from different sources in a multicast environment and the interleaving of PDU's as seen by the receiver. Multicast ARP mechanisms should be explored as experience from these experiments Laubach [Page 6] DRAFT Classical IP and ARP over ATM July 1993 can contribute directly to the definition of multicast address services in future ATM-FORUM standards activities. The multicast ARP model will be more fully detailed in a future document. ATM hardware addresses are formatted as ATM-FORUM compliant NSAP's [9]. ARP request and reply formats are discussed in the section on Address Resolution. It is RECOMMENDED that routers providing LIS functionality over the ATM network also support the ability to interconnect differing LIS's. Routers that wish to provide interconnection of differing LIS's MUST be able to support multiple sets of these parameters (one set for each connected LIS) and be able to associate each set of parameters with a specific IP network/ subnet number. In addition, it is RECOMMENDED that a router be able to provide this multiple LIS support with a single physical ATM interface that may have one or more individual ATM addresses. 7. Packet Format The default packet format for IP datagrams SHALL be the IEEE 802.2 LLC/SNAP format as described in [2]. This memo recognizes the future development of end-to-end signalling within ATM that will allow negotiation of encapsulation method on a per-VC basis. Signalling negotiations are beyond the scope of this document. 8. MTU Size The default MTU size for IP stations operating over the ATM network SHALL be 9180 octets. The LLC/SNAP header is 8 octets, therefore the maximum ATM AAL5 protocol service unit size will be 9188 octets. In classical IP subnets, values other than the default can only be used provided that all stations on the LIS can be configured to use the non-default value. The minimum IP MTU size is 576 octets [8]. The LLC/SNAP header is 8 octets, therefore the minimum ATM AAL5 protocol data unit size will be 584 octets. This memo recognizes the future development of end-to-end signalling within ATM that will allow negotiation of MTU size on a per-VC basis. Signalling negotiations are beyond the scope of this document. 9. Address Resolution Laubach [Page 7] DRAFT Classical IP and ARP over ATM July 1993 The dynamic mapping of 32-bit Internet protocol addresses to ATM hardware addresses within an LIS SHALL be done via the dynamic discovery procedure of the Address Resolution Protocol (ARP) [3]. The configuration of static mapping or the treatment of ARP within an LIS supporting only PVC's is beyond the scope of this document. Internet addresses are assigned independent of ATM addresses. Each host implementation MUST know its own internet and ATM address(es) and respond to Address Resolution requests appropriately. Hosts MUST also use ARP to map Internet addresses to ATM addresses when needed. The ARP protocol has several fields that have the following format and values: Data: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type ar$shln 8 bits Octet length of source hardware address (m) ar$spln 8 bits Octet length of source protocol address (n) ar$op 16 bits Operation code (request or reply) ar$thln 8 bits Octet length of target hardware address (p) ar$tpln 8 bits Octet length of target protocol address (q) ar$sha moctets source hardware address ar$spa noctets source protocol address ar$tha poctets target hardware address ar$tpa qoctets target protocol address Where: ar$hrd - assigned to NSAP address family and is dd decimal (0x00nn) [4]. ar$pro - see Assigned Numbers for protocol type number for the protocol using ARP. (IP is 0x0800). ar$shln - length of the source hardware NSAP address length. ar$spln - length in bytes of the source protocol address. For IP ar$spln is 4. ar$op - 1 for request and 2 for reply ar$thln - length of the target hardware NSAP address length. ar$tpln - length in bytes of the target protocol address. For IP ar$tpln is 4. ar$sha - source NSAP address. Laubach [Page 8] DRAFT Classical IP and ARP over ATM July 1993 ar$spa - source protocol address. ar$tha - target NSAP address. ar$tpa - target protocol address. The ATM hardware addresses in ARP packets (ar$sha, ar$tha) SHALL be ATM-FORUM specified NSAP addresses [9]. The same NSAP encoding SHALL be used within an LIS and replies will use the same encoding as queries. For example, NSAP's may encode IEEE 48-bit MAC addresses or may encode E.164 addresses. Within the LIS either IEEE MAC or E.164 hardware addresses may be used but not both. ARP packets are to be encoded in AAL5 PDU's using LLC/SNAP encapsulation. The format of the AAL5 CPCS-SDU payload field for routed non-ISO PDU's is: Payload Format for Routed non-ISO PDU's +------------------------------+ | LLC 0xAA-AA-03 | +------------------------------+ | OUI 0x00-00-00 | +------------------------------+ | Ethertype 0x08-06 | +------------------------------+ | | | ARP Packet | | | +------------------------------+ The LLC value of 0xAA-AA-03 (3 bytes) indicates the presence of a SNAP header. The OUI value of 0x00-00-00 (3 bytes) indicates that the following two-bytes is an ethertype. The Ethertype value of 0x08-06 (2 bytes) indicates ARP [4]. The total size of the LLC/SNAP header is 8-bytes fixed length. This aligns the start of the ARP packet on a 64-bit boundary relative to the start of the AAL5 SDU. The LLC/SNAP encapsulation for ARP presented here is consistent with the treatment of multiprotocol encapsulation of IP over ATM AAL5 as specified in [2] and in the format of ARP over IEEE 802 networks as specified in [5]. Laubach [Page 9] DRAFT Classical IP and ARP over ATM July 1993 Traditionally, ARP requests are broadcast to all directly connected IP stations within a LIS. It is conceivable in the future that larger scaled ATM networks may "broadcast" ARP requests to destinations outside the originating LIS, perhaps even globally; issues raised by broadcasting outside the LIS or by a global ARP mechanism are beyond the scope of this document. 10. IP Broadcast Address ATM hardware multicast service addressing is not yet a conformance requirement of the ATM-FORUM. As such, there is no consistent facility in local area network ATM switches for hardware multicast addressing. Experimentation with ATM multicast addresses in the Internet community however, must be supported. The ATM-FORUM does specify point-to-point and point-to-multipoint addressing [9]. The following scenarios apply to the multicast and non-multicast situations: 1. ATM multicast available: if the switch fabric connecting the host ATM interface supports multicast, then the Internet broadcast address (the address on that network with a host part of all binary ones) MUST map to an ATM group address that includes all IP stations within the LIS. 2. No ATM multicast support: the Internet broadcast address MUST map to atm$arp-req, and atm$arp-req MUST either map to the local IP host ATM hardware address or the ATM hardware address of an ARP server located within the LIS, if available. If the LIS is operating in the ARP Server model, the station acting as the ARP server must relay IP packets received on an ARP unicast query VC onto the point-to-multipoint ARP reply VC. In all cases, encapsulated IP packets sent to the IP broadcast address may be received on the ARP query VC by any station. This requires that IP packets sent to the IP broadcast address use LLC/SNAP encoding and that all stations examine the value of ethertype in the LLC/SNAP header and process IP versus ARP accordingly on all packets received on this VC. 11. IP Multicast Address IP multicast address mappings to ATM point-to-multipoint or group addresses are not discussed in this memo. 12. Security Security issues are not discussed in this memo. Laubach [Page 10] DRAFT Classical IP and ARP over ATM July 1993 This memo recognizes the future development of ATM and IP facilities for authenticated call setup, authenticated end-to-end application knowledge, and data encryption as being required services for globally connected ATM networks. These future security facilities and their use by IP networks are beyond the scope of this document. 13. Open Issues There are some open issues: o A proposal was put before the Internet Assigned Numbers Authority to approve a request to create an ARP hardware type of "NSAP family address". IANA has not responded as of this date. My hopes are that we can get an ARP type created now that will cover NSAP's for all time. o Well known ATM hardware address(es) for ARP servers? It would be very handy if we came up with a set of well known ATM addresses for ARP services. We should probably have well-known PVC numbers for a non-SVC environment also. o Interim Local Management Interface (ILMI) services will not be generally implemented by some providers and vendors and will not be used to obtain the ATM address network prefix from the network. Meta-signalling does provide some of this functionality and in the future we need to document the options. REFERENCES [1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS Service", RFC1209, USC/Information Sciences Institute, March 1991. [2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", work in progress, IETF IP over ATM Working Group, February 1993. [3] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, MIT, November 1982. [4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC1340, USC/ Information Sciences Institute, July 1992. [5] Postel, J., and Reynolds, J., "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC1042, USC/Information Sciences Institute, February 1988. Laubach [Page 11] DRAFT Classical IP and ARP over ATM July 1993 [6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII, Geneva, 19-29 January 1993. [7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September - 2 October 1992. [8] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC1122, USC/Information Sciences Institute, October 1989. [9] ATM-FORUM, "ATM User-Network Interface Specification Version 3.0. (DRAFT)", June 1993. Author's Address Mark Laubach Hewlett-Packard Laboratories 1501 Page Mill Road Palo Alto, CA 94304 Phone: 415.857.3513 FAX: 415.857.8526 EMail: laubach@hpl.hp.com Laubach [Page 12]